SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
VB6

VB6 static code analysis

Unique rules to find Bugs, Security Hotspots, and Code Smells in your VB6 code

  • All rules 45
  • Bug1
  • Security Hotspot1
  • Code Smell43
 
Tags
    Impact
      Clean code attribute
        1. "GoTo" statements should not be used

           Code Smell
        2. "GoSub" statements should not be used

           Code Smell
        3. "Option Explicit" should be enabled

           Code Smell
        4. Track parsing failures

           Code Smell
        5. "Select Case" statements should not be nested

           Code Smell
        6. Variable data types should be declared explicitly

           Code Smell
        7. The bang ("!") operator should not be used

           Code Smell
        8. Multiple variables should not be declared on the same line

           Code Smell
        9. "Option Base" should not be used

           Code Smell
        10. Loop invariants should not be calculated inside the loop

           Code Smell
        11. "Asc[W]" should not be called on string constants

           Code Smell
        12. "Chr[W]$()" should not be used for certain characters

           Code Smell
        13. '$' should not be used in string variable names

           Code Smell
        14. String-specific functions should be used

           Code Smell
        15. Strings should not be set to empty string

           Code Smell
        16. Strings should not be compared with empty string

           Code Smell
        17. The "&" operator should be used to concatenate strings

           Code Smell
        18. Sub and function names should comply with a naming convention

           Code Smell
        19. Subs and functions should not be too complex

           Code Smell
        20. "Select Case" statements should not have too many "Case" clauses

           Code Smell
        21. Comments should not be located at the end of lines of code

           Code Smell
        22. Subs and functions should not have too many lines

           Code Smell
        23. "Select" statements should end with a "Case Else" clause

           Code Smell
        24. "Select Case" statements should have at least 3 "Case" clauses

           Code Smell
        25. Statements should be on separate lines

           Code Smell
        26. Methods should not be empty

           Code Smell
        27. "Case" clauses should not have too many lines

           Code Smell
        28. Constant names should comply with a naming convention

           Code Smell
        29. Track uses of "TODO" tags

           Code Smell
        30. Track uses of "FIXME" tags

           Code Smell
        31. Lines should not end with trailing whitespaces

           Code Smell
        32. Return of boolean expressions should not be wrapped into an "if-then-else" statement

           Code Smell
        33. Boolean literals should not be redundant

           Code Smell
        34. Source code should be indented consistently

           Code Smell
        35. Empty statements should be removed

           Code Smell
        36. Magic numbers should not be used

           Code Smell
        37. Nested blocks of code should not be left empty

           Code Smell
        38. Procedures should not have too many parameters

           Code Smell
        39. Unused private variables should be removed

           Code Smell
        40. Expressions should not be too complex

           Code Smell
        41. Tabulation characters should not be used

           Code Smell
        42. Files should not have too many lines of code

           Code Smell
        43. Lines should not be too long

           Code Smell

        Track uses of "TODO" tags

        intentionality - complete
        maintainability
        Code Smell
        • cwe

        Why is this an issue?

        More Info

        Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately. However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase. This description explores why this is a problem and how it can be fixed to improve the overall code quality.

        What is the potential impact?

        Unattended TODO tags in code can have significant implications for the development process and the overall codebase.

        Incomplete Functionality: When developers leave TODO tags without implementing the corresponding code, it results in incomplete functionality within the software. This can lead to unexpected behavior or missing features, adversely affecting the end-user experience.

        Missed Bug Fixes: If developers do not promptly address TODO tags, they might overlook critical bug fixes and security updates. Delayed bug fixes can result in more severe issues and increase the effort required to resolve them later.

        Impact on Collaboration: In team-based development environments, unattended TODO tags can hinder collaboration. Other team members might not be aware of the intended changes, leading to conflicts or redundant efforts in the codebase.

        Codebase Bloat: The accumulation of unattended TODO tags over time can clutter the codebase and make it difficult to distinguish between work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.

        Addressing this code smell is essential to ensure a maintainable, readable, reliable codebase and promote effective collaboration among developers.

        Noncompliant code example

        Rem TODO Add documentation
        Sub DoSomething()
            ' TODO
        End Sub
        
          Available In:
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Enterprise
          Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use